Three read sites opened frozen artifacts with no integrity check at all, while
the directory holding them is demonstrably writable -- one file in it was
overwritten on 2026-07-25. "The harness reconciled against whatever was on disk"
was never hypothetical, so C5's four legs went green against inputs nothing had
authenticated. (They are intact today: verify passes 15/15 panels and 14/14
cells, so no C5 conclusion is in question. Both facts are true and neither alone
is the whole story.)

A/B -- the two frozen-panel reads. `verified_frozen_panel_path` is now THE only
gateway: `frozen_panel_path` is called nowhere else in the module, enforced by
AST, because checking "is this read verified?" per site makes it a per-site
question and the site that forgets is the one that will not announce itself.
The anchors leg's tolerance for an absent panel became `required=False` rather
than a second bare call, which is what collapsed the two callers into one.

Per-panel, not a whole-tree sweep: the harness runs per factor, and verifying
fifteen panels to read one (3.0s vs 0.2s) makes the check something people
switch off, and a check that is disabled because it is slow protects nothing.
The jump fork is followed off the PATH, not re-derived from the factor id: both
trees hold a jump_amount_corr_20.parquet and they are DIFFERENT definitions
(v1.0 untruncated, v1.1 truncated), so re-deriving would eventually drift from
what frozen_panel_path actually picked. Written in a code comment, not only in
the review thread.

C-1 -- the hand-anchor record. It was the one file under refactor_baseline/ that
no manifest covered and the one that actually got overwritten. Its sha256 now
lives in git (docs/factors/d5_hand_anchor_record_manifest.json) while the record
stays gitignored -- the same split as everywhere else, so an overwrite cannot
move its own expectation without appearing in git diff.

Pinned rather than regenerated on purpose: the C5 anchors leg closed 11/11
against THESE bytes, and the stronger provenance form needs a rerun, which would
overwrite them. That would leave a C5 leg verified against a record that no
longer exists.

The manifest states the record's inventory AND the inventory is checked, not
merely written down -- because the pinned record is INCOMPLETE:
daily_engine_compared is 0 rows and cannot be refilled. Pinning an incomplete
record is fine; letting a later reader take "pinned" for "complete" is not. A
test asserts the manifest says so, including that the D2 conclusion itself
survives elsewhere ("88 hand anchors, 0 mismatches", PR #89). The inventory
check also catches what a sha alone cannot: a rerun that drops rows and has its
sha refreshed to match.

D-1 -- the write side. hand_anchor_rows now refuses to overwrite an existing
record without --allow-overwrite, naming the keys this run would drop, computed
by DIFFERENCE against what it produces so a future key needs nobody to remember
a list. The check runs BEFORE the ~7 minutes of hand computation: a refusal that
arrives at the end of a long run teaches people to pass the override by reflex.
PRODUCED_RECORD_KEYS is asserted against the actual payload at write time, so
the set the guard reasons about cannot drift from what is written.

D-3 (carrying the old daily_engine_compared forward) stays rejected and is
recorded as rejected: it would splice a comparison made against older engine
values onto a freshly recomputed frozen14 -- internally inconsistent, worse than
honestly missing. Writing down the tempting option that lost is more useful than
only writing down the one that won.

Two things found while building this, both fixed:
- the CLI shim's `except RecordOverwriteRefused` did not catch. Under `python -m
  qt.hand_anchors_d2` the module is loaded twice, as __main__ and as
  qt.hand_anchors_d2, so the class raised and the class caught were different
  objects and the guard surfaced as a traceback with its handler right there.
- the first mutation aimed at A/B had NO teeth: reverting the read site to the
  bare path broke nothing, because no test pinned the wiring -- only the routing.
  That is what prompted the single-gateway restructure; the property is now
  checkable and the mutation is red. 25/25 mutations have teeth.

C-2 (record the panels_d2 hashes inside the record) and D-4 (move it out of a
directory documented as un-regenerable, which it is not) are registered in the
catalogue for a follow-up that must also re-verify the anchors leg. They are one
piece of work, and this PR's job is deletion.

`artifacts/` -- with a trailing slash -- matches only a directory, so it never
matched the `artifacts` SYMLINK the git worktrees carry (pointing at the main
checkout). That left it untracked-but-addable, and a `git add -A` in this PR duly
committed a machine-specific absolute-path symlink plus two generated phase0
outputs.

This belongs in this PR rather than a later one: the PR exists to make "frozen
bytes stay out of git" true in fact, and the root cause was that the rule was
never correctly expressed. Two lines remove the whole class.

The symlink was caught by
test_frozen_bytes_are_untracked_while_the_manifest_is_tracked, which guards the
split every tamper check here rests on -- if the bytes and their hashes both
lived in git, one commit could move them together and the checks would be
decorative. It fired at exactly the right moment.

`artifacts_local_phase0/` needs its own line: `artifacts` does not match it, and
NO test guards it, so the identical accident there would have been silent. The
guard is deliberately not extended to cover it -- it is not load-bearing for the
frozen design, and widening a guard's range inside a deletion PR is how range
creeps.

Evidence, before and after, with the change asserted to have landed
(.gitignore sha e1f17c45 -> 9791dd9b):

  before: git add -A --dry-run  ->  artifacts
                                    artifacts_local_phase0/logs/run_phase0.log
                                    artifacts_local_phase0/reports/phase0_summary.md
  after : git add -A --dry-run  ->  .gitignore   (this change only)

  git check-ignore -v  ->  .gitignore:21:artifacts             artifacts
                           .gitignore:24:artifacts_local_phase0/ artifacts_local_phase0

No tracked path contains "artifacts", so the broader pattern cannot mask
anything already in the repository.

…st that it works

Review MEDIUM-1. `load_anchor_rows`'s call to `verify_anchor_record` was pinned
by nothing: the reviewer replaced it with `pass` and the whole suite stayed green
-- 2661 passed, rc=0, identical to the unmutated tree.

This is my own failure form, surviving in the third read site after I fixed it in
the other two. The first A/B mutation was empty for exactly this reason: six
tests exercised the verifier thoroughly, and none said "the read site must call
it". Fixing the panels side by collapsing to a single gateway did nothing for the
anchors side, because a lesson applied only where it was learned is not applied.

Behavioural, not AST, and the reason is the failure it has to catch: an AST
assertion proves the call is written down. A call with the wrong argument, or one
whose exception is swallowed, satisfies AST and stops nothing. So the test builds
a miniature repo_root, tampers the record AFTER its manifest is written (bytes
drift, expectation does not -- the real shape), and demands a refusal. A second
mutation proves the distinction is not theoretical: swallowing the exception
while keeping the call is now red too, and AST would have passed it.

A green control comes first -- an intact record must return its rows -- because
"it raised" means nothing from a function that raises at everything. The
reviewer made the same point about its own R5: the control must be ACCEPTED
first or every subsequent REFUSED is empty.

Also pinned: the check runs BEFORE parsing. An unparseable tampered record must
fail as an integrity mismatch, not as a JSON error that never names the real
problem.

Review LOW-1. `top_level_keys` was stated in the manifest and never compared --
INVENTORY_FIELDS held four count-shaped fields. The reviewer added
`all_ok_daily: true`, refreshed the sha, and it was ACCEPTED, while the
manifest's most prominent prose says precisely that key is absent. So
"pinned is not complete" was resting on prose, and prose stops nothing.

Counts cannot see a key appear or vanish; the key SET can. It is now compared
like every other inventory field. Note this makes the catalogue's existing claim
-- that the inventory is machine-checked rather than prose -- true of all five
fields, where it had been true of four.

Mutations: 28/28 with teeth, three new. #23 is the reviewer's own, reproduced
verbatim.

NIT-1 (the FAMILY regex not matching a parenthetical) is left alone as ruled:
pre-existing, byte-identical to main, and no actual exposure -- both members of
that family are cited by name elsewhere and remain covered by the exists-and-is-
unique check.

…ally blocks

Review finding, and the same defect class this repository keeps catching: a
guard whose DECLARED range is wider than what it blocks. Precedent for the fix
is `_complete_grid_bars`, which states its exposure per caller rather than
asserting a general property.

The function docstring promised the inventory catches "a manifest updated to
match a new file without anyone noticing what changed inside it (in particular, a
daily_engine_compared that silently went to zero)". From the CURRENTLY PINNED
record that case cannot occur: the loss already happened, what is pinned is the
state after it, and the field is already at zero.

Measured at the real pinned shape (70 / 20 / 0 / False) rather than reasoned:

  untouched                        -> ACCEPTED   (control)
  rerun, sha NOT refreshed         -> REFUSED    (the sha catches it)
  rerun, sha honestly refreshed    -> ACCEPTED   <- inventory contributes nothing
  daily_engine_compared 0 -> 20    -> REFUSED    <- inventory does bite here

A plain rerun keeps every count and the key set identical -- same seed, same
stratified selection -- while the values move. So on that path the protection is
the human reading the git diff, not this check. Adding top_level_keys did not
change this: a rerun does not move the key set either.

Both halves are now in the docstring, because either alone misleads: "the
inventory is checked" invites more confidence than it earns on the rerun path,
and "the inventory is useless" is false in the other direction.

Two tests measure the range instead of restating it -- one asserting the
LIMITATION (rerun + refreshed sha is accepted) and one the residual teeth (a
shape change is refused). The limitation test is deliberately shaped so that
strengthening the check later makes it fail: that is the signal to update the
RANGE section in the same commit, so the claim cannot drift wider than the code
again. A third test pins the docstring itself, whitespace-normalised -- these
sentences wrap, and a raw substring match would be testing line breaks rather
than the claim (the same wrapped-string trap already hit once in this suite).

Mutations 30/30, two new: restoring the unreachable promise, and stating the
limitation without saying what covers it instead. Both turn the docstring test
red.

… wide

Follow-up to 0d91164, prompted by the standing rule that a claim wider OR
narrower than the behaviour both count as unfixed. Narrower is a real defect,
not pedantry: it invites someone to add a redundant guard for something already
covered.

The first version said the inventory "bites where counts or keys move".
Measured, that understates it: ``all_ok_frozen14`` is a bool verdict flag —
neither a row count nor a key — and it IS compared.

  counts identical, key set identical, all_ok_frozen14 False -> True,
  sha honestly refreshed                                     -> REFUSED

So the range now names all three things the shape comprises: the three counts,
the key set, and the verdict flag. And the exemption is restated as what it
actually is — an UNCHANGED SHAPE, not the act of rerunning. A rerun today lands
in the exemption because same seed gives the same counts and keys and the same
inputs give the same flag; a rerun whose flag flipped would be caught.

Tests now measure all three directions rather than two: the limitation
(unchanged shape plus refreshed sha is accepted), rows gained, and the flag
flip — the last with explicit premise assertions that no count and no key moved,
so it cannot pass for the wrong reason. The docstring test pins the widened
wording, including that it must not read "counts or keys".

Mutations 31/31; the new one narrows the claim back and turns the docstring
test red.